1. Field of the Invention
The present invention relates to the field of inter-process and intra-process communications, and more particularly to port and protocol sharing among multiple server processes.
2. Description of the Related Art
Inter-process and intra-process communications relates to the exchange of electronic data between two or more computing processes, or within a single computing process, in a computer communications network. Traditionally, inter-process and intra-process communications in the context of the Internet protocol involves the addressing of information for delivery to a computing process at a specific network address using a specific port therein. In this regard, the combination of the address and port, referred to as a socket, can form the basis of sockets based communications. To effectively deploy a server based computing process, then, an address and port for the server based computing process first must be established for the benefit of client computing processes accessing the server computing process.
Most computing server processes provide access thereto through a published or conventionally established port. For instance, hypertext transfer protocol (HTTP) data messages typically can be processed through port 80 of a server process, or occasionally, port 8080. By comparison, the file transfer protocol (FTP) can operate through port 21. Both cases illustrate the principle that common Internet services use well-known ports because most applications, particularly Internet services, do not know how many logical ports within a host platform will be available at any one moment and how those logical ports may be configured. Accordingly, rather than forcing a server process to change its configuration to accommodate a new application, the applications typically use well known ports that are supported by all server processes.
Because server processes use well-known ports, server processes may be limited to providing a single Internet service within a single host. This limitation can be logical result of the requirement that the server process monitor the configured port for requests and responses directed to the server process. Typically, all messages received over the monitored port are deemed to have been directed to the server process. Thus, where multiple server processes “listen on” the same port, confusion can result and substantial logic and a proprietary configuration will be required to overcome this naturally arising confusion. Additionally, where a firewall has been deployed, oftentimes only a few select ports are open for communications by default.
U.S. Pat. No. 6,950,873 to Jain et al., hereinafter the “Jain patent”, which has been commonly assigned to International Business Machines Corporation, addresses the deficiencies of the assignment of a port to a single server process. In the Jain patent, it is proposed that multiple processes can share a single port by virtue of a shared port mapping layer. The shared port mapping layer can act as an intermediate “traffic cop”. Incoming traffic on the shared port can be resolved to back end specific ports through a mapping of the domain name associated with the incoming traffic to the back end specific port. In this way, though the host may be limited in its exposure of logical ports to external client processes, multiple server processes can listen on non-traditional, unused ports without requiring the exposure of those non-traditional ports. Moreover, client processes can continue to rely upon the traditional association of particular server process types with specific, well-known ports.
Despite the advancement demonstrated within the Jain patent, a level of extensibility preferred in the art can be lacking therein. Specifically, to add new server processes to the list of server processes sharing a particular port will require a disruptive modification to the mapping table itself Moreover, as the mapping relates specifically to the domain of the server process, the port sharing technology of the Jain patent does not account for applications which conform to a layered architecture, rather than a monolithic architecture. Layered applications reflect the deconstruction of a monolithic application into interdependent layers. Data flowing between the layers can be variably and selectably routed to different layers in the hierarchy. Consequently, a tremendous run-time flexibility can result including a flexibility to distribute the application across different threads and process address spaces.